Security at the Edge

The Internet has become an essential part of daily life for almost everyone in society having grown far beyond its roots in the 1970s as the ARPANET, a network that was principally the domain of scientists and engineers. The popularity of the HTTP, developed at CERN in the late 1980s led to the widespread use of the term ‘the web’ as a generic name for the Internet for many years, at least in the public domain. Of course, the Internet is much more than just web browsing and, in recent years, the term cyberspace has become the most popular term to describe interactions over the Internet. Yet, an unambiguous definition of the term is difficult to formulate . Financial institutions underpinning the economy and the operation of national critical infrastructures, such as monitoring and control of the electricity supply, are now dependent on the Internet. A consequence of this is that cyberattacks become more costly for the victims and perversely more attractive to the criminals who carry them out . The advent of the Internet of Things (IoT) and edge computing as a new paradigm creates the potential for enhanced productivity but at the same time opens up new opportunities for cyberattacks while still being exposed to existing attach vectors such as the well-known denial of service attack (DDoS), which can take place in many forms . In this chapter, we described the challenges in building an edge system that is secure against cyberattack. We begin by briefly reviewing the architecture of communications over the Internet and later consider the new challenges that follow from operating the hardware with values of voltage, frequency and current that enable more energy efficiency

Feature Guided Architecture Development for Embedded System Families

Software product-line engineering aims to maximize reuse by exploiting the commonality within families of related systems. Its success depend on capturing the commonality and variability, and using this to evolve a reference architecture for the product family. With embedded system families, the possibility of variability in hardware and operating system platforms is an added complication. In this paper we outline a strategy for evolving reference architectures from bi-directional feature models. The proposed strategy complements information provided by the feature model with scenarios that help to elaborate feature behavior

A Multiple Views Model for Variability Management in Software Product Lines

\With current trends towards moving variability from hardware to software, and given the increasing desire to postpone design decisions as much as is economically feasible, managing the variability from requirements elicitation to implementation is becoming a primary business requirement in the product line process. Nowadays, a medium size software system may encompass hundreds if not thousands of variability points introducing a new level of complexity that current techniques struggle to manage. In this paper, we present a new approach to variability management by introducing a multiple views model (4VM) where each view caters for specific set of concerns that relate to a particular group of stakeholders

Weaving Behaviour into Feature Models for Embedded System Families

Product Line software Engineering depends on capturing the commonality and variability within a family of products, typically using feature modeling, and using this information to evolve a generic reference architecture for the family. For embedded systems, possible variability in hardware and operating system platforms is an added complication. The design process can be facilitated by first exploring the behavior associated with features. In this paper we outline a bi-directional feature modeling scheme that supports the capture of commonality and variability in the platform environment as well as within the required software. Additionally, ‘behavior’ associated with features can be included in the overall model. This is achieved by integrating the UCM path notation in a way that exploits UCM’s static and dynamic stubs to capture behavioral variability and link it to the feature model structure. The resulting model is a richer source of information to support the architecture development process

Requirements Modelling and Design Notations for Software Product Lines

Although feature modelling is a frequently used approach to the task of modelling commonality and variability within product lines, there is currently no standard modelling notation or methodology. On the assumption that the commonality/variability model will be used as a basis for architecture design, our modelling notation allows features to be augmented with behavioural detail, captured using the UCM path notation. This gives rise to models that capture commonality and variability in behaviour as well as in product features, and are thus more valuable for downstream design activities. This paper outlines the modelling notation and describes ongoing work on the characterisation of variability points within models based on this notation, and on the relationships between model fragments and solution domain techniques such as design patterns or variability realisation techniques. It also describes preliminary work, aimed at evolving an intelligent tool that can characterise feature and behavioural model fragments and suggest design and realisation methods

Challenges in the Application of Feature Modelling in Fixed Line Telecommunications

The global telephone system is a complex transmission network, the features of which are defined to a very high level by ITU-T standards. It is therefore a prime candidate at which to target the application of software product line techniques, and feature modelling in particular, in order to handle the inherent commonality of protocols and variability in equipment functionality. This paper reports on an experimental feature modelling notation and illustrates it with application to the modelling of embedded software for the core network elements. We look at three of the fundamental challenges facing the adoption of feature modelling in the field and explain how we have strived to address these within our tools set